A framework for the definition of metrics for actor-dependency models

Actor-dependency models are a formalism aimed at providing intentional descriptions of processes as a network of dependency relationships among actors. This kind of models is currently widely used in the early phase of requirements engineering as well as in other contexts such as organizational analysis and business process reengineering. In this paper, we are interested in the definition of a framework for the formulation of metrics over these models. These metrics are used to analyse the models with respect to some properties that are interesting for the system being modelled, such as security, efficiency or accuracy. The metrics are defined in terms of the actors and dependencies of the model. We distinguish three different kinds of metrics that are formally defined, and then we apply the framework at two different layers of a meeting scheduler system.Postprint (published version

PABRE-Proj: applying patterns in requirements elicitation

© 2013 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Software requirement patterns have been proposed as a type of artifact for fostering requirements reuse. In this paper, we present PABRE-Proj, a tool aimed at supporting requirements elicitation and specification.Peer ReviewedPostprint (author's final draft

Determinació d'esquemes d'interacció en models conceptuals orientats a objectes amb interacció implícita

Postprint (published version

A catalogue of non-technical requirement patterns

© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Software Requirement Patterns (SRP) have been proposed as an artifact for fostering requirements reuse. PABRE is a framework that promotes the use of SRP as a means for requirements elicitation, validation and documentation in the context of IT procurement projects. In this paper, we present a catalogue of non-technical SRP included in the framework and present in detail some of them. We also introduce the motivation to arrive to these patterns.Peer ReviewedPostprint (author's final draft

A framework for selecting workflow tools in the context of composite information systems

When an organization faces the need of integrating some workflow-related activities in its information system, it becomes necessary to have at hand some well-defined informational model to be used as a framework for determining the selection criteria onto which the requirements of the organization can be mapped. Some proposals exist that provide such a framework, remarkably the WfMC reference model, but they are designed to be appl icable when workflow tools are selected independently from other software, and departing from a set of well-known requirements. Often this is not the case: workflow facilities are needed as a part of the procurement of a larger, composite information syste m and therefore the general goals of the system have to be analyzed, assigned to its individual components and further detailed. We propose in this paper the MULTSEC method in charge of analyzing the initial goals of the system, determining the types of components that form the system architecture, building quality models for each type and then mapping the goals into detailed requirements which can be measured using quality criteria. We develop in some detail the quality model (compliant with the ISO/IEC 9126-1 quality standard) for the workflow type of tools; we show how the quality model can be used to refine and clarify the requirements in order to guarantee a highly reliable selection result; and we use it to evaluate two particular workflow solutions a- ailable in the market (kept anonymous in the paper). We develop our proposal using a particular selection experience we have recently been involved in, namely the procurement of a document management subsystem to be integrated in an academic data management information system for our university.Peer ReviewedPostprint (author's final draft

DesCOTS-SL: a tool for the selection of COTS components

DesCOTS is a system that has an aim to help clients in the selection of COTS components. This system is based in the use of quality models associated to a software domain for evaluating the products in that domain, and for defining in a formal way the requirements of the clients for finding a suitable product in that domain. The evaluation and the formal definition of requirements are facilitated by metrics of each quality entity in the quality models. Our ISO/IEC 9126-1 based quality models are a set of quality entities structured in hierarchies of characteristics, subcharacteristics and attributes; with possible intermediate hierarchies of sub-characteristics and attributes.Peer ReviewedPostprint (published version

DesCOTS-EV: a tool for the evaluation of COTS components

In the last years, some methods have been proposed for dealing with COTS component selection. In all of them, a key point is the comparison of the user requirements, which drive the selection process, with the capabilities of the evaluated COTS. Quality models are a means to obtain structured descriptions of COTS domains. Once built, COTS in a domain may be evaluated with respect to the quality entities included therein, quality requirements may be stated with respect to the quality model, and the classical factor-requirement negotiation process may be used for the selection of the most appropriate COTS. Our goal is to have completely implemented in a near future a new version of the system DesCOTS (Grau et al., 2004) that supports all the above processes. This system is constituted by 4 subsystems: QM, that helps in the construction and management of quality models (Carvallo et al., 2004); EV, that helps in the evaluation of COTS components and that is the one presented in this paper; SL, that helps in the definition of requirements in a project and in the selection of COTS components that hold these requirements; and AD, that allows the administration of the whole system.Peer ReviewedPostprint (published version

Requirements reuse and requirement patterns: a state of the practice survey

Context. Requirements engineering is a discipline with numerous challenges to overcome. One of these challenges is the implementation of requirements reuse approaches. Although several theoretical proposals exist, little is known about the practices that are currently adopted in industry. Objective. Our goal is to contribute to the investigation of the state of the practice in the reuse of requirements, eliciting current practices from practitioners, and their opinions whenever appropriate. Besides reuse in general, we focus on requirement patterns as a particular strategy to reuse. Method. We conducted an exploratory survey based on an online questionnaire. We received 71 responses from requirements engineers with industrial experience in the field, which were analyzed in order to derive observations. Results. Although we found that a high majority of respondents declared some level of reuse in their projects (in particular, non-functional requirements were identified as the most similar and recurrent among projects), it is true that only a minority of them declared such reuse as a regular practice. Larger IT organizations and IT organizations with well-established software processes and methods present higher levels of reuse. Ignorance of reuse techniques and processes is the main reason preventing wider adoption. From the different existing reuse techniques, the simplest ones based on textual copy and subsequent tailoring of former requirements are the most adopted techniques. However, participants who apply reuse more often tend to use more elaborate techniques. Opinions of respondents about the use of requirement patterns show that they can be expected to mitigate problems related to the quality of the resulting requirements, such as lack of uniformity, inconsistency, or ambiguity. The main reasons behind the lack of adoption of requirement patterns by practitioners (in spite of the increasing research approaches proposed in the community) are related to the lack of a well-defined reuse method and involvement of requirement engineers.Peer ReviewedPostprint (author's final draft

Determining criteria for selecting software components: lessons learned

Software component selection is growing in importance. Its success relies on correctly assessing the candidate components' quality. For a particular project, you can assess quality by identifying and analyzing the criteria that affect it. Component selection is on the suitability and completeness of the criteria used for evaluation. Experiences from determining criteria for several industrial projects provide important lessons. For a particular selection process, you can organize selection criteria into a criteria catalog. A CC is built for a scope, which can be either a domain (workflow systems, mail servers, antivirus tools, and so on) or a category of domains (communication infrastructure, collaboration software, and so on). Structurally, a CC arranges selection criteria in a hierarchical tree-like structure. The higher-level selection criteria serve to classify more concrete selection criteria, usually allowing some overlap. They also serve to leverage the CC.Peer ReviewedPostprint (published version

Building and using quality models for complex software domains

The use of quality models in software package procurement provides a framework for the description of the domain which the package belongs to. Package descriptions and user quality requirements may be translated into the quality concepts defined in the model making package procurement more efficient and reliable. In this paper we address the construction of quality models for complex software domains, defined as domains that imply a mixture of functionalities. Procurement processes taking place in complex domains require not a single package to be selected but a set of them. As a consequence, instead of a standard, single quality model, we need a more elaborated quality model for driving the simultaneous procurement of multiple software packages. We describe the parts that compose these kind of models, the methodology for building them and their usage in software procurement. We apply the approach to the complex domain of mail server systems.Preprin